Chris Pollett > Old Classes >
CS174

( Print View )

Student Corner:
  [Grades Sec1]

  [Submit Sec1]

  [Class Sign Up Sec1]

  [
Lecture Notes]
  [Discussion Board]

Course Info:
  [Texts & Links]
  [Topics/Outcomes]
  [Outcomes Matrix]
  [Grading]
  [HW Info]
  [Exam Info]
  [Regrades]
  [Honesty]
  [Additional Policies]
  [Announcements]

HWs and Quizzes:
  [Hw1]  [Hw2]  [Hw3]
  [Hw4]  [Hw5][Quizzes]

Practice Exams:
  [Mid1]  [Final]

                           












HW#2 --- last modified February 17 2019 19:28:34..

Solution set.

Due date: Oct 4

Files to be submitted:
  Hw2.zip

Purpose:To develop our first PHP project using a model view controller pattern.

Related Course Outcomes:

LO1 -- Write HTML documents containing standard HTML elements including forms, tables, client-side scripts, and server-side scripts.

LO3 -- Write server-side scripts that process HTML forms.

Specification:

For this homemwork you will create a website called TrivialWiki. If you don't know what a wiki is please see this article on wikis. Before we describe how TrivialWiki will look and work, let's spend a moment describing how your code should be organized, what requests coming into your website should look like, and overall how your code should work.

You should organize the files of your project as follows:

  • Project Root/
    • index.php
    • config/
    • controllers/
    • models/
    • pages/
    • views/
    • css/

Access to your site will be through URLs of the form:

BASEURL/index.php?c=controllername&a1=arg1&a2=arg2...

Here BASEURL is the URL for where your site is hosted. Nowhere in your code should you hard code/force the value of this. controllername is the name of the controller requested, it should correspond to the name of a file in the controllers folder. For example, c=foo would say use the file controllers/foo.php as the controller. Remember URLs always use forward slashed, so use controllers/foo.php in your code not controllers\foo.php. The name value pairs a1=arg1, etc. correspond to arguments you would like to send to the given controller -- these may or may not be present depending on the controller. On any access to your site, your index.php script should first include files from the config folder. This folder should contain as few files as possible. The purpose of these files should be to set up any variables that might need to change if you deployed your program on a different site. The config folder should also have a readme.txt file telling the grader what needs to be changed in config files to get your site running. Be aware that making the grader work too hard to get your site running will result in a lower score. The grader has the discretion regardless of the point values listed in the table below to reduce your score to 0 if your site is too hard to deploy.

If someone goes to your TrivialWiki site and does not provide a query string, or provides a query string in the wrong format, your site should act as if the request was to:

BASEURL/index.php?c=main&p=1&v=display

Roughly, this says use the file controllers/main.php to access page 1 of the wiki in display mode. main.php should use functions in the model, models/page.php, to read the data stored in the file pages/p_1.txt. Then main.php should set up a $data global which it gives the view views/display.php to draw the web page that the user sees. The basic split of work is as follows: A controller is used to figure out from the request which models are needed to get data to handle the request. A controller then might do some calculation on the data it gets back from the models. The controller then sets up the $data variable, selects a view and tells it to draw. A model is responsible for accessing storage that persists between requests such as data stored in a file or a database. For example, for TrivialWiki, we will use the model models/pages.php to read and write wiki pages to and from the filesystem. A controller should never be allowed to directly access the filesystem or database. Finally, a view is responsible for drawing web pages. Neither controllers nor models should ever output anything. A view is not allowed to perform any calculations beyond doing echo's like: <?php echo $data['some_field']; ?>. I will allow your index.php file to render a common header and footer for all pages on your site.

Given the framework, set up above, if somebody comes into your site at BASEURL, they should see the first page of the wiki. Each wiki page has two modes (which should correspond to two views) in which it can be seen: display mode and edit mode. In display mode the wiki page cannot be edited. A display mode page should have a TrivialWiki Banner on the top and left of the page and then floated to the right should either be the single link SignIn, or three links in an inlined, unordered list: Edit, New, and SignOut. The TrivialWiki Banner should be a link which always links back to the first wiki page. The css styles for the banner and link should all be external and be stored in css files in the css folder. All code including styles (no yui) should be entirely your own. Beneath this you should have a two column layout done with div tags. The left column should be at most 2.5 inches wide and have an h2 tag saying "Places to Go", underneath which is an unordered list of links to other TrivialWiki pages. The right column is allowed to take up the remainder of the width of the page. It should have an h1 title tag with a title for the wiki page, beneath this in pre tags is the actual content of the wiki page. The text for wiki page links should come from the title of the respective page.

As we said main.php should use the model models/page.php to read in the data for the links, the title, and page content. For page n in the wiki this should be stored in pages/p_n.txt . The format of this is up till the first newline character is assumed to be the title; thereafter, each subsequent pair of lines until a line with === on it is assumed to be a line with a url followed by line with url text. All the data after the === line is assumed to be the content of the wiki page.

main.php should use a function in model models/authenticate.php to determine whether to display a single SignIn link or Edit, New, and SignOut. The controller the SignIn link should use is controllers/signin.php. This should render to the user a view views/signin.php where they can enter a username and a password. The signin controller should also use a function in the model models/authenticate.php to check this username and password. To keep things simple authenticate.php should just keep a hard-coded associative array of valid usernames and passwords to do this check. If a login is unsuccessful the signin controller should display a view views/signin_fail.php with an error message and a link back to where they could enter the login and password again. If a login is successful the signin controller should display a view views/signin_success.php with a successful message and a link page to the wiki page the user just came from.

It should be the case that the user must be signed-in to access the sites that the Edit and New links point to. i.e., they shouldn't be able to copy what the links would be into the browser and go to those pages without signing in. The idea of the Edit link page is that it should let the user edit the current wiki page. The New link should create a new wiki page (with number one bigger than the biggest numbered page so far) which is linked-to from the current wiki page. The new wiki page should also get a link back to what was the current wiki page. Aside from the fact that the New link creates a new file and modifies an old file, the view displayed after clicking either link should be the same: views/edit.php. Also, in both cases, controller/main.php should be the controller. main.php should use functions in models/page.php to read in/write out the data to/from the appropriate pages/p_n.txt pages. As we said, it should display the view views/edit.php . This view should have a form with a labeled title text field, and a labeled content text area. This form should have in hidden variables all of the link information for the page. The form should have two buttons a save button and a cancel button. The cancel button should return the user to the state they were in before that came to the Edit/New page form. Clicking the Save button should save the changes and go to whatever the page that was just saved was. After saving, this page should be rendered in display rather than edit mode.

That's it! This completes the description of TrivialWiki. Below is the point breakdown.

Point Breakdown

Folder set-up as described and URLs used as described (1/2pt each)1pt
config directory is used as described and has a readme.txt that is accurate1pt
At least one external stylesheet is used. It should make use of class, and id selectors1pt
main.php controller invokes functions in models/page.php when it needs to read or write wiki pages.1pt
wiki pages stored in the format described above.1pt
main.php sets up views as described above.1pt
SignIn, Edit, New, SignOut links works as described.1pt
signin.php controller works/sets up views as described above1pt
The views/edit.php form is as described and works.1pt
authenticate.php model used/works as described, $_SESSION used.1pt
Total10pts